Before we delve into the features on the client side
in SQL Server, it’s important to make note of a few server-side
features. This information will help you gain an understanding of which
networking features are initially configured on the server (after an
installation or upgrade) as well as how incoming connections are dealt
with. Such knowledge can be invaluable in diagnosing connectivity
issues.
The following sections
describe how to set up the server’s basic network configuration,
including configuring it to accept remote connections, learning which
protocols it supports, and understanding how it listens for and responds
to client requests.
Server Network Protocols
The first and most basic
step after a SQL Server installation or upgrade is to make sure the
appropriate network protocols are configured on the server.
Note
Note that the term server is used here to refer to an instance of the SQL Server 2008 Database Engine. The term client
is used generally to mean any program that needs to communicate with a
server. The server and client may reside on the same physical machine
(especially when using SQL Server Mobile and Express Editions).
First, you should ensure
that the protocols your clients once used to connect to SQL Server 7,
2000 or 2005 (or that your clients would like to use) are still
supported by SQL Server 2008 and configured.
You might be surprised to
learn that the following protocols that were supported in SQL Server
2000 are not supported by SQL Server 2005 or SQL Server 2008:
AppleTalk
Banyan VINES
Multiprotocol
NW Link IPX/SPX
If you were using these
protocols and you’ve upgraded from SQL Server 2000, your clients are no
longer able to connect. Following are the only protocols that SQL
Server 2008 supports:
If you were using any of
these protocols and you just upgraded, Setup copies your pre-upgrade
settings over to SQL Server 2008, including the enabled state, IP
addresses, TCP ports, pipe names, and so on. Clients can simply test
their connections to be sure the upgrade was successful, and in most
cases, no changes need to be made.
Note
The Shared memory protocol
works only for connections both to and from the same machine hosting the
Database Engine. Shared memory is used by client tools such as SQL
Server Management Studio (SSMS) and SQLCMD, and it’s also a good choice
for use by locally running custom applications because it is secure by
design. (It is the default protocol used by local applications that do
not specify otherwise.)
All remote connections to SQL
Server are thus disabled by default. Following is an extremely common
client-side error message illustrating connection failure due to
disabled remote connectivity:
A network-related or instance-specific error occurred while
establishing a connection to SQL Server. The server was not found
or was not accessible. Verify that the instance name is correct and
that SQL Server is configured to allow remote connections.
The exact wording of this
message varies slightly, depending on the particular client or
connection method used. The same error also occurs when the Database
Engine service is stopped.
In SQL Server 2008,
remote connections must be enabled for each network protocol on which
you want the server to communicate. This is easily accomplished using
the SQL Server Configuration Manager (SSCM). You launch SSCM from the
SQL Server 2008 Configuration Tools menu group. In SSCM, you expand SQL Server Network Configuration and then select the Protocols
entry for the SQL Server instance that you want to configure. In the
Details pane, right-click on one of the available protocols (for
example, Named Pipes) and select Enable to allow connections for this
protocol (see Figure 1).
When the protocol is
enabled, SQL Server is configured to listen for connections from clients
using the same protocol. You must restart the SQL Server instance for
the changes to take effect and for SQL Server to actually start
listening for connections. You can verify that SQL Server is listening
on the protocol that you have enabled by looking at the SQL Server error
log. Each time the SQL Server instance is restarted, messages are
written to the log indicating which protocols it is listening on. The
following sample error log messages show what SQL Server is listening
for:
Server is listening on [ 'any' <ipv4> 1719].
Server named pipe provider is ready to accept connection on
[ \\.\pipe\MSSQL$INST2008\sql\query ].
SQL
Server listens on all configured protocols simultaneously, giving no
preference or priority to any. This is in contrast to the explicitly
prioritized manner in which clients attempt to connect via all
configured protocols.
Note
In SQL Server 2005, the
Surface Area Configuration (SAC) tool also could be used to allow remote
connections and to configure the protocols on which they communicate.
The SAC tool has been removed in SQL Server 2008, so you need to look to
the SSCM to configure your protocols.
The Server Endpoint Layer
A networking feature in
SQL Server 2008 adds an additional layer to the client/server network
structure: Tabular Data Stream (TDS) endpoints. When you install (or
upgrade to) SQL Server 2008, a default system endpoint is created on the
server for each available protocol on the server. These endpoints
cannot be dropped, and they are created regardless of whether the
protocol is disabled or otherwise unavailable.
Note
The term endpoint
in this context refers to the combination of a protocol selection, one
or more IP addresses (or pipe names), and any associated port numbers.
These are the default system endpoints:
You can view these endpoints and check their status by executing the following T-SQL statement:
Use Master
GO
SELECT * FROM sys.endpoints WHERE principal_id = 1
By default, all users are granted access to these endpoints (except the DAC, which is only for members of the sysadmin
role). Administrators can create new endpoints on the server to
increase connection security by stopping (or disabling) the default
system endpoints and then creating new user-defined endpoints that only
specific clients can access. (Creating a new system endpoint automatically revokes permission on the default endpoint of the same protocol to the public group.)
Note
Only one named pipe and one
shared memory endpoint can exist per instance, but multiple VIA or TCP
endpoints (with different port and address settings) can coexist.
Each endpoint communicates
with clients via TDS packets, which are formatted on the server side by
SNAC and on the client side by SNAC or another of the net-libraries.
Administrators have
the option of stopping and starting endpoints while sessions are still
active, preventing new connections from being made while still
supporting existing ones.
An administrator can
grant or revoke endpoint access to specific users or groups (for
example, preventing backdoor access through client tools). It is
therefore important for clients to know that this structure exists and
to learn how they receive permission to connect to endpoints through a
server-side process known as provisioning.
Client Access Provisioning
There are three
fairly straightforward rules of access provisioning. If any one of these
rules is met by an incoming client, that client may access the
endpoint. If none are met, the client is denied access. These are the
rules:
If the client
specifies an IP address and a TCP port that match those of a specific
endpoint, the client may connect to it, if the client has permission to
do so.
If
only the TCP port specified by the client matches that of a specific
endpoint, and the endpoint is configured to listen on all IP addresses,
the client may connect to it, if the client has permission to do so.
If
neither the TCP port nor IP address is specified, but the default
endpoint for the protocol is enabled, the client may attempt to connect
to the endpoint.
Note
If the endpoint to which
access is successfully provisioned is currently stopped, or if the user
does not have permission to connect to it, no further endpoints are
tried and the client cannot continue.
For example, let’s say a server has three TCP/IP endpoints defined:
The default (TSQL Default TCP), which listens on all IP addresses and Port 1433 (a default SQL Server 2008 instance)
A user-created endpoint called TCP_UserCreated 101_91, configured to listen on IP address 192.168.1.101 and Port 91
A second user-created endpoint, called TCP_UserCreated Any_91, which is configured to listen on all IP addresses and Port 91
A client attempts to connect
specifically to 192.168.1.101:91. Because this is an exact address and
port match, the client can try to connect to TCP_UserCreated 101_91. Having an exact address and port match meets the first provisioning rule.
A second client attempts to
connect to any IP address on Port 91. Because there is no exact address
match, the client cannot attempt to connect to TCP_UserCreated 101_91. However, the client can attempt to connect to TCP_UserCreated Any_91 because it is configured to listen on all IP addresses. This meets the second provisioning rule.
A third client attempts to connect on any port and any address. If TSQL Default TCP is started, the client is granted permission to attempt to connect. This meets the third provisioning rule.
Tip
If, at any time, you want
to discover which protocol and endpoint a connected client is currently
using, you can run the following T-SQL to list the current connections
and related protocols. The session_id identifies the server process ID (SPID), and an additional WHERE clause can be added to the SELECT statement that selects only the SPID you are interested in:
SELECT name, net_transport, session_id, e.endpoint_id
FROM sys.dm_exec_connections d
JOIN sys.endpoints e
ON e.endpoint_id = d.endpoint_id
go
name net_transport session_id endpoint_id
TSQL Local Machine Shared memory 53 2
Following is an example of the client-side error message that results if the TSQL Default TCP endpoint is stopped and you try to connect to it:
A connection was successfully established with the server, but then an error
occurred during the login process
Now that you know a bit about endpoints, let’s go a bit deeper and explore how client connections are facilitated on the server.
The Role of SQL Browser
You might be surprised to
learn that when clients try to connect to SQL Server 2008, their first
network access is made over UDP Port 1434 to the SQL Browser service.
Note
Regardless of the
encryption status of the connection itself, login credentials are always
encrypted when passed to SQL Server 2008 (to foil any malicious packet
sniffing). If a certificate signed by an external authority (such as
VeriSign) is not installed on the server, SQL Server automatically
generates a self-signed certificate for use in encrypting login
credentials.
SQL Browser is the upgrade
to the SQL Server Resolution Protocol (SSRP) and its job is to hand out
instance names, version numbers, and connection information for each
(nonhidden) instance of the Database Engine (and Analysis Services)
residing on a server—not only for SQL Server 2008 instances, but for SQL
Server 2000 and 2005 instances as well.
When clients connect by
name, SQL Browser searches for that name in its list and then hands out
the connection data for that instance. It can also provide a list of
available servers and help make connections to the correct server
instance or to make a connection on the dedicated administrator
connection (DAC).
Ports, Pipes, and Instances
Default instances of SQL
Server 2008 are automatically configured (just as in previous editions)
to listen on all IP addresses and TCP Port 1433.
Named instances, on the
other hand, are automatically configured to listen on all IP addresses,
using dynamic TCP port numbers that change when the Database Engine is
restarted. (Most often, these change only when the port number last used
by the service is in use by a different application.)
If the SQL Browser
service is not running, the client might need to provide additional
connection information to be able to connect to SQL Server. The
additional connection information includes the specific port or pipe
that the SQL Server instance may be listening on. The only exception to
this is if the server is listening on the default port of 1433.
Otherwise, the client must specify the port when connecting with TCP/IP.
When dynamic ports are used, the port number can change at any given
time and cause your clients to have to change their port to match the
new server port.
SQL Browser, therefore, is
configured to autostart on servers that contain one or more named
instances so that clients can connect by simply providing the server
name. The complexity associated with providing additional port or pipe
information is avoided when the
SQL Browser service is running. SQL Browser is also required for
enumerating the server lists used to connect with client tools such as
SMSS.
Note
If named instances have
fixed port numbers known to clients, or if a pipe name is well known,
SQL Browser is not required to connect.
Note
For named pipes, the default instance’s pipe name is \sql\query; for named instances, the pipe name is MSSQL$instancename\sql\query.
When a link is made, endpoint provisioning kicks in to finalize (or reject) the connection.
